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Abstract 

Information  technology  is  more  and  more  a vitally  impor- 
tant underpinning  to  our  economy  and  to  our  society.  It  is 
embedded  in  everyday  applications  and  animates  a wide 
class  of  systems  that  range  from  small  to  large  and  from 
simple  to  extremely  sophisticated.  Among  the  probable 
threats  for  military  information  systems,  the  presence  of 
malicious  code  within  COTS  applications  has  been  identi- 
fied as  a major  risk  that  has  not  received  a lot  of  attention. 
Like  a virus  that  has  infiltrated  an  information  system  dur- 
ing an  electronic  information  exchange,  malicious  code 
integrated  into  a commercial  application  could  remain  un- 
detected and  present  a major  risk for  the  safety  of  informa- 
tion within  a military  system.  In  this  paper,  techniques  to 
detect  malicious  code  within  commercial  applications  are 
reviewed.  Emphasis  is  placed  upon  the  certifying  com- 
piler, which  enforces  a formal  security  specification  while 
compiling  the  source  code.  This  emerging  technology  of- 
fers the  most  comprehensive  and  sustainable  approach  for 
large  applications  and  for  the  periodic  certification  of  up- 
grades. 


1 Introduction 

The  Defence  Research  Establishment,  Valcartier  (DREV) 
carries  out  an  extensive  R&D  program  in  Command  and 
Control  Information  Systems  (CCIS)  for  the  Canadian  De- 
partment of  National  Defence  (DND).  During  the  Infor- 
mation Warfare  Workshop  held  in  Ottawa  in  Oct.  ’96, 
several  R&D  challenges  were  identified  and  presented  to 
DND  and  industry  representatives  [17].  Trusted  software 
design  and  validation  was  one  of  the  areas  where  addi- 
tional effort  was  deemed  necessary  to  meet  DND  needs. 
Of  particular  concern  was  the  integration  of  Commercial- 
Off-The-Shelf  (COTS)  software  into  military  information 
systems. 


Exploiting  COTS  software  through  integration  poses  a 
distinct  dilemma.  On  one  hand,  COTS  software  is  very 
attractive;  its  use  promises  to  reduce  development  time 
and  costs.  On  the  other  hand,  it  introduces  new  risks  into 
military  information  systems:  hidden  functionalities,  trap 
doors,  private  control  codes  giving  enhanced  privileges, 
logical  or  temporal  bombs  [6],  etc. 

A feasibility  study  completed  in  1998  indicates  that  a 
variety  of  software  analysis  techniques  can  be  applied  to 
the  management  of  the  risk  associated  with  COTS  soft- 
ware in  military  information  systems.  Among  them,  the 
exploitation  of  certifying  compilers  appears  to  be  a very 
powerful  technology  for  the  efficient  yet  exhaustive  verifi- 
cation of  software  with  minimal  human  supervision.  This 
paper  summarises  the  lessons  learned  in  the  MaliCOTS 
project,  earned  out  jointly  by  DREV  and  Laval  Univer- 
sity. The  proposed  strategy  will,  after  successful  imple- 
mentation, ensure  the  safe  integration  of  previously  un- 
trusted software  in  military  information  systems  via  certi- 
fying compilers. 

2 Malicious  Code 

Malicious  codes  are  fragments  of  programs  that  can  af- 
fect the  confidentiality,  the  integrity,  the  data  and  control 
flow,  and  the  functionality  of  a system  without  the  ex- 
plicit knowledge  and  consent  of  the  user.  We  distinguish 
between  intentionally  malicious  and  unintentionally  mali- 
cious code.  Malicious  individuals  who,  for  example,  use 
such  programs  to  access  confidential  data  generally  intro- 
duce the  first.  The  second  is  due  to  inadvertent  human 
error,  especially  during  development  of  the  software. 

To  detect  malicious  code  in  COTS  software,  one  must 
be  able  to  distinguish  between  its  types.  Starting  from  the 
taxonomy  proposed  by  McDermott  & Choi  [12],  a new 
taxonomy  has  been  defined  that  is  specifically  intended  to 
facilitate  the  detection  of  malicious  code  in  COTS  soft- 
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Figure  1 : Potential  techniques  to  detect  malicious  code  in  COTS  software 


ware  [3]. 

One  of  the  key  concepts  of  the  MaliCOTS  project  is  al- 
ways to  refer  to  a security  policy  to  distinguish  an  accept- 
able activity  from  a potential  threat.  It  reflects  the  fact  that 
software  functionalities  can  never  be  considered  malicious 
in  and  of  themselves;  even  reformatting  a disk  or  destroy- 
ing a file  are  useful  operations  in  certain  circumstances; 
that  is  why  such  capabilities  were  devised  and  made  avail- 
able to  system  users.  But  in  many  operational  contexts 
these  functions  should  not  be  made  available  to  end-users 
because  of  the  associated  risks.  The  most  rigorous  way  to 
enforce  such  a policy  is  to  formalise  these  constraints  ex- 
plicitly in  a security  specification  based  upon  permissible 
access  mechanisms.  This  strategy  is  documented  in  more 
detail  in  this  paper. 

In  practice,  threat  that  system  analysts  are  typically 
concerned  with  are: 

• the  presence  of  trapdoors  in  COTS  packages  (as 
found  in  Unix,  Windows  NT  & ’98  [6, 9]), 

• license  expiration  logic  [16], 

• hidden  communications  (e.g.,  a CD  player  software 
that  is  repotted  to  send  ’your  listening  preferences’ 
to  a distributor  periodically  [15]),  and 

• other  undesirable  functionalities  such  as  those 
present  in  the  flight  simulator  in  Excel  ’97  and  the 
Word  ’97  pinball  machine  [3,2]. 

The  next  section  summarises  the  feasibility  study, 
completed  in  fall  1998,  into  ways  to  detect  such  malicious 
code. 

3 Technology  Options  to  Detect  Ma- 
licious Code  in  COTS  Software 

Figure  1 identifies  a variety  of  techniques  applicable  to  the 
MaliCOTS  project,  in  order  of  increasing  level  of  com- 


plexity. 

Reference  [4]  contains  a comparative  analysis  of  these 
techniques.  In  summary,  ad  hoc  techniques  consist  of  code 
inspection  in  search  of  a known  malicious  signature  or  its 
generalisation  (often  called  a heuristic).  This  approach 
has  been  very  successful  in  detecting  viruses  within  ex- 
changed files,  but  its  effectiveness  in  detecting  malicious 
code  in  large  software  applications  is  limited  since  a priori 
knowledge  is  needed  (i.e.,  either  signature  or  behaviour 
profiles). 

Static  analysis  of  code  comes  from  the  world  of  pro- 
gram optimisation  and  software  analysis.  It  consists  of 
examining  the  code  (perhaps  in  some  abstract  representa- 
tion) without  running  it.  At  present,  static  analysis  is  es- 
sential to  COTS  certification  because  it  gives  a relatively 
precise  idea  of  program  behaviour  for  all  possible  execu- 
tion conditions.  However,  the  technique  is  limited  in  capa- 
bility, especially  when  source  code  is  not  available,  which 
is  typically  the  case  for  COTS.  The  process  requires  enor- 
mous human  effort  for  very  large  applications  [5]. 

Dynamic  techniques  examine  the  behaviour  of  the 
code  while  it  is  running.  Such  analysis  is  a pragmatic 
approach  that  offers  short-term  benefits.  Many  variants 
are  available:  monitoring  execution,  running  an  exhaus- 
tive suite  of  tests,  injecting  faults  in  critical  variables  or 
wrapping  the  commercial  code  into  a software  shell  that 
detects  and  filters  out  unwanted  activities.  Another  paper 
presented  in  this  conference  deals  with  dynamic  detection 
and  provides  supplementary  information  [18]. 

Each  of  these  techniques  has  its  place  and  offers  short- 
term solutions  to  the  detection  of  malicious  code  in  COTS 
software.  However,  they  are  all  reactive,  in  the  sense  that 
they  evaluate  the  COTS  package  after  development,  when 
detection  is  made  mote  difficult  by  the  lack  of  access  to 
source  code. 

Being  unsatisfied  with  this  situation,  we  have  searched 
for  a truly  innovative  approach  to  COTS  integration 
that  will  overcome  existing  difficulties  with  the  non- 
availability of  source  code,  with  time-consuming  manual 
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Figure  2:  Certifying  compiler  — basic  concept 


inspection  of  software  and  with  difficulty  in  ensuring  the 
completeness  of  verification. 

Certifying  compilers  have  emerged  as  an  extremely 
powerful  technology  to  manage  the  risk  associated  with 
COTS  integration.  The  basic  idea  is  to  put  enough  "intel- 
ligence" into  the  compiler  that  it  will  not  only  produce  the 
executable  code  but  also  perform  formal  security  verifica- 
tion. As  shown  in  Figure  2,  the  compiler  needs  two  inputs: 
the  source  code  and  the  security  policy.  The  compiler  then 
translates  the  source  code  into  the  appropriate  intermedi- 
ate language  (e.g.,  assembly,  byte  code,  etc.)  along  with 
embedded  security  annotations. 

The  next  section  describes  the  concept  and  gives  a 
practical  fed  of  its  capabilities  in  our  particular  context, 

4 Certifying  Compilers;  Concept  & 
Practice 

4.1  Concept 

As  in  human  health,  prevention  is  certainly  the  best  cure. 
So  it  is  worthwhile  from  a security  standpoint  to  elaborate 
methodologies  that  guarantee  that  COTS  software  prod- 
ucts are  free  of  any  malicious  code  from  the  start.  In  order 
to  do  that,  we  propose  the  inclusion  of  intelligence  in  the 
compiler  to  allow  enforcement  of  a security  specification 
while  compiling. 

Figure  3 illustrates  the  most  general  scheme  to  pro- 
duce trusted  software  while  compiling.  The  first  step  con- 
sists of  compiling  the  source  code  and  introducing  static 
annotations  in  the  object  file  (i.e.,  byte  code  for  JAVA,  as- 
sembly language  or  other  intermediate  language).  It  is  a 
rather  simple  and  mechanical  process  to  introduce  the  an- 
notations. Secondly,  the  annotated  code  is  submitted  to 


a verifier  (or  a verifying  linker)  that  enforces  a formally 
expressed  security  specification.  By  doing  so,  the  final  ex- 
ecutable application  can  be  assembled  safely  and  sealed 
with  a security  tag  before  integration  into  a critical  infor- 
mation system. 

This  is  a very  flexible  approach.  Not  only  can  the  an- 
notations be  produced  rapidly  and  independently  of  the  fi- 
nal integration  but  also  different  local  security  policies  can 
be  enforced  in  different  parts  of  an  organisation  on  a single 
annotated  component.  Another  great  advantage  of  this  ap- 
proach is  that  there  is  no  need  for  the  software  integrator  to 
have  access  to  the  source  code.  The  only  requirement  for 
the  software  producer  is  to  adopt  an  annotation  structure 
that  the  integrator  can  recognise  and  verify  for  correctness. 
This  key  feature  protects  the  intellectual  property  of  soft- 
ware producers. 

The  second  step  of  the  process  (verification)  starts  with 
a comparison  of  the  annotations  with  the  object  code.  Any 
anomalies  in  the  compliance  of  the  code  with  the  anno- 
tations can  easily  be  flagged  for  further  investigation.  In 
other  words,  if  the  code  is  modified  after  it  was  annotated, 
or  if  the  annotations  are  changed  without  any  code  modifi- 
cation, the  verifier  will  rapidly  detect  it.  The  only  compo- 
nent that  one  must  trust  in  this  system  is  the  verifier  itself; 
there  is  no  need  for  trustworthiness  in  the  code  producer, 
the  annotating  compiler  or  the  transmission  channel  up  to 
the  verifier.  This  is  a very  important  feature  for  security 
architects,  who  may  deal  with  the  trustworthiness  of  only 
one  component,  the  verifier. 

4.2  Annotation  Structures 

So  far  we  have  not  described  the  content  and  the  struc- 
ture of  the  annotations  the  compiler  produces.  Many  op- 
tions exist,  each  with  its  advantages  and  disadvantages.  In 


13-4 


Figure  3:  Certifying  compiler  — generalized  concept 


the  MaliCOTS  projects,  we  examined  three  possibilities 
closely: 

• PCC  (Proof  Carrying  Code),  developed  under  the 
leadership  of  Peter  Lee  and  George  Necuia  at  CMU 
(Carnegie  Mellon)  and  at  Berkeley  University; 

• ECC  (Efficient  Code  Certification),  led  by  Dexter 
Kozen  from  Cornell;  and 

■ TAL  (Typed  Assembly  Language),  designed  by 
Greg  Morissett  at  Cornell  University. 

PCC  is  a technique  to  ensure  the  safe  execution  of  un- 
trusted mobile  code.  When  code  is  transferred  between 
a client  and  a producer,  the  producer  must  append  to  the 
code  a formal  proof  that  it  is  consistent  with  some  shared 
security  policy.  The  client  can  easily  check  the  proof  by 
using  a simple  and  easy-to-trust  proof  checker.  PCC  is  a 
very  comprehensive  and  secure  approach  [14]. 

ECC  was  designed  to  be  a much  lighter  solution  to 
code  certification.  The  annotations  contain  structured  in- 
formation that  qualifies  the  safety  of  the  code.  It  was  de- 
signed for  efficiency  and  performance,  sacrificing  some  of 
the  rigour  of  other  approaches  [10]. 

TAL  proposes  to  introduce  "type"-typing  information- 
into  the  code.  Basically,  software  types  are  static  descrip- 
tors of  logical  entities  (e.g.,  variables,  constants,  character 
strings. . . ) and  of  how  they  are  used  in  the  code.  These 
annotations  are  light  and  informative  and  can  easily  be 
produced  and  managed  within  a comprehensive  security 
policy  [13]. 

TAL  was  selected  as  the  technology  of  choice  for  the 
detection  of  malicious  code  in  COTS  software.  Type  an- 
notations provide  an  automatic  way  to  verify  that  a pro- 
gram will  not  violate  safety  properties  and,  potentially, 


high-level  security  requirements.  At  this  time,  TAL  can 
handle: 

• control  flow  safety  (i.e.,  programs  cannot  jump  to 
code  that  was  not  verified  and  stack  preservation  is 
enforced), 

• memory  safety  (i.e.,  access  to  initialised  memory  lo- 
cations and  array  bounds  checking)  and 

• type  safety  (i.e.,  the  compatibility  of  types  in  opera- 
tions). 

Complementary  annotations  in  the  "ECC  style"  will 
be  considered  later  in  the  MaliCOTS  project  if  they  are 
needed. 

In  summary,  type  annotations  are  static  approxima- 
tions of  the  behaviour  of  the  program.  Essentially,  they 
correspond  to  typing  preconditions  on  code  labels.  Before 
transferring  control  to  any  label,  the  register,  stack  and 
relevant  variables  must  contain  values  of  the  types  spec- 
ified. The  type-checker  matches  each  instruction  operand 
against  these  constraints  to  ensure  that  they  do  not  violate 
safety  properties. 

4.3  Example 

To  illustrate  the  concept  of  annotations,  we  will  now 
examine  a simple  program  written  in  C (Code  Excerpt  l) 
and  compile  it  to  assembly  language  with  annotations 
(TALx86  code)  as  shown  in  Code  Excerpt  2,  where  an- 
notations appear  in  bold.  An  expression  such  as  "eax:  B4" 
indicates  that  the  register  "eax"  must  contain  four  bytes  if 
the  following  instruction  is  to  be  executed.  Inference  rules 
are  used  to  verify  formally  that  all  conditions  are  met  be- 
fore the  activation  of  a given  operand  (e.g.,  an  arithmetic 
operation  or  a call  procedure  like  those  shown  in  Figure  4). 
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Code  Excerpt  1:  Sample  C code 

Mefine  TABLEAU  100 
unsigned  int  premier eTABLEAU; 

int  estPremier(  int  nombre,  int  compte  ) 

{ 

int  i = 0; 

int  iPremier  = 1;  //sans  preuve  du  contraire.,  e'estun  nombre  premier 

for  (i  - 0;  i < compte;  i++) 

{ 

if  ( nombre  % premiers i ■«  0 ) 

{ 

iPremier  - 0; 

break; 

} 

} 

return  iPremier; 

} 


( ArithBin ) 


£ h opi  : -B4  e r opj  : 54  e h V alidBinops{op\,op-i)  e j-  Writeablejopi) 

c I-  arithbin  opi,op2  : £ 


(Call) 


£ H cop  :{<?;}  g F gi(esp)  = sptr{g2  ::  c*}  g I-  g-7[eap  ; ftptr{g2  ::  (gQrfesp))}]  j gi 

e h call  cop  : e[7  : 52] 


Figure  4;  Two  inference  rules  enforcing  annotation  checking  in  TAL 


As  part  of  the  MaliCOTS  project,  we  are  developing  an 
ANSI  C compiler  that  will  produce  assembly  language  for 
x86  processors  along  with  the  corresponding  TAL  anno- 
tations. Our  compiler  is  based  on  LCC  (Lean  retargetable 
C Compiler);  a public-domain  compiler  that  is  well  docu- 
mented and  for  which  source  code  is  available  [7].  A beta 
version  of  our  TalCC  compiler  is  available  for  government 
release,  to  allow  a broader  community  to  become  familiar 
with  the  annotation  technology.  More  information  can  be 
obtained  from  the  authors  of  this  paper. 

For  next  year,  we  are  planning  the  development  of  a 
JAVA  annotating  compiler  that  exploits  the  same  anno- 
tation structure  as  TalCC.  It  will  probably  be  based  on 
J1KES,  an  IBM  shareware  compiler  that  is  part  of  Linux 
packages.  Emerging  commercial  products  will  also  be 
considered  ([1 1]). 

5 Discussion  & Conclusion 

In  view  of  budget  reductions  and  decreasing  human  re- 
sources, integration  of  COTS  software  appears  to  be  the 
only  sustainable  approach  for  Canadian  DND  [8],  At 
the  present  time,  system  analysts  have  only  such  labour- 
intensive  techniques  as  static  and  dynamic  verification  to 
certify  COTS  software.  It  is  expected  that  these  techniques 
will  remain  useful  (and  mandatory,  in  many  instances)  for 


the  certification  of  COTS  packages.  The  MaliCOTS  team 
values  them  greatly  and  attempts  to  integrate  them  into  a 
common  framework. 

However,  it  is  evident  that  more  efficient  and  less  time- 
consuming  techniques  are  needed  to  handle  COTS  soft- 
ware, especially  when  periodic  upgrades  must  be  certified 
and  when  security  policies  must  be  met  that  vary  signifi- 
cantly throughout  an  organisation. 

Certifying  compiler  is  a powerful  enabling  technol- 
ogy to  meet  this  challenge.  By  formally  specifying  lo- 
cal security  policies  and  by  annotating  an  intermediate 
form  of  the  code,  the  whole  process  is  brought  under  con- 
trol. Marginally  acceptable  functionalities  and  suspicious 
code  segments  may  require  later  manual  inspection,  but 
the  software  core  can  be  certified  autonomously  by  the 
verifier. 

This  approach  is  also  general  enough  to  contribute 
to  other  kinds  of  certification,  including  interoperability 
compliance,  reuse  policy,  maintainability  specifications, 
etc.,  which  are  not  examined  by  the  MaliCOTS  team  at 
this  time.  Once  these  additional  policies  are  expressed 
formally,  simply  passing  the  verifier  over  the  annotated 
code  would  enforce  them.  Even  though  they  are  simple 
and  compact,  type  annotations  are  very  expressive.  Our 
R&D  on  the  detection  of  malicious  code  confirm  that  they 
have  a strong  potential  for  structuring  and  normalising  Use 
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integration  of  COTS  software  into  critical  systems. 

The  expected  benefits  of  certifying  compilation  are  ex- 
tensive and  far-reaching.  We  hope  that  this  paper  will 
create  enough  interest  in  the  technology  that  international 
collaboration  can  be  organised  to  explore  this  ambitious 
certification  paradigm  more  fully. 
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Code  Excerpt  2:  Corresponding  assembly  language  with  annotations  in  TAL 

_estPremier: 

LABELTYPE  <A1I[  si:  Ts.nl:  Sint  ].{  ESP:  sptr|S{0)]  {{  ESP:  fptr(S(0)]  B4::B4::tl , 

EBP:  sptrfS(nl)]  si , EAX:  B4  })Ax::B4::B4::sl . EBP:  sptr(S(nl)]  si } > 
push  ebx 
push  esi 
push  edi 
enter  8,0 
L8: 

LABELTYPE <AU[  si:  Ts.nl:  Slnl  |.{  ESP:  splr(S(0)]  B4Au::B4Au::B4Ax::B4Ax::B4Ax::B4Ax:: 

({  ESP:  sptr(S<0)]  B4::B4::s1 , EBP:  sptr|S(nl)|  si , EAX:  B4  })Ax::B4::B4::sl , EBP: 
sptr|S(-8)|  B4Au::B4Au::B4Ax::B4Ax::B4Ax::B4Ax::({  ESP:  sptr[S(0)]  B4::B4::sl  .EBP: 
sptr|S(nl»  si , EAX:  B4  })Ax::B4::B4::sl  } > 
mov  dword  ptr  (-4) [ebp] ,0 
mov  dword  ptr  (-8) [ebp] , l 
mov  dword  ptr  ( -4 ) [ebp]  , 0 
jmp  tapp(  L5 , < el,  nl  > ) 

L2: 

LABELTYPE  < AU|  si:  Ts.nl:  Sint  ].{ ESP:  sptr[S(0)j  B4Arw::B4Arw::B4  Ax::B4Ax::B4Ax::B4Ax:: 

({ ESP:  sptr|S(0)|  B4::B4::sl , EBP:  sptr[S<nl)l  si , EAX:  B4  })Ax::B4::B4::sl , EBP: 
sptr|S(-8)]  B4Arw::B4Arw::B4Ax::B4Ax::B4Ax::B4Ax::({  ESP:  sptr|S(0)|  B4::B4::sl  ,EBP: 
sptr|S(nl)]  si , EAX:  B4  })Ax::B4::B4::sl } > 
mov  edi, dword  ptr  (20)  [ebp] 
mov  eax.edi 

mov  edi, dword  ptr  (-4)  [ebp] 

mov  edi, dword  ptr  (^premiere) [edi*4] 

xor  edx,edx 

div  edi 

cmp  edx, 0 

jne  tapp(  L6,  < si,  nl  > ) 

L9 : 

LABELTYPE  < All[  si:  Ts.nl:  Sint  ].{ ESP:  sptr|S(0)l  B4Arw::B4Arw::B4Ax::B4Ax::B4Ax::B4Ax:: 

({ ESP:  sptrlS(O)]  B4::B4::sl , EBP:  sptr[S(nl)]  si , EAX:  B4  })Ax::B4::B4::sl , EBP: 
sptr[S(-8)]  B4Arw::B4Arw;:B4Ax::B4Ax::B4Ax::B4Ax::({  ESP:  sptr|S<0)i  B4::B4::sl , EBP: 
sptr[S(nl)l  si , EAX:  B4  })Ax::B4::B4::sl  } > 
mov  dword  ptr  ( - 8 ) [ebp] , 0 
jmp  tapp(  L4,  csl.nl?) 

L6: 

LABELTYPE  < All[  si:  Ts.nl:  Sint  l.{  ESP:  iptr[S(0)]  B4Arw::B4Arw::B4Ax::B4Ax::B4Ax::B4Ax:: 

({  ESP:  sptr(S(0)l  B4::B4::sl , EBP:  sptr[S(nl)|  si , EAX:  B4  })Ax::B4::B4::sl , EBP: 
sptr(S(-8)]  B4Arw::B4Arw::B4Ax::B4Ax::B4Ax::B4Ax::((  ESP:  sptrlS(O)]  B4::B4::sl , EBP: 
sptr|S(nl)]  si , EAX:  B4  })Ax::B4::B4::sl } > 

L3: 

LABELTYPE  < AU(  si:  Ts.nl:  Sint  ].{ ESP:  sptr(S(0)]  B4Arw::B4Arw::B4Ax::B4Ax::B4Ax::B4Ax:: 

({ ESP:  sptr(S(0)]  B4::B4::sl , EBP:  sptr(S{nl)]  si , EAX:  B4  })Ax::B4::B4::sl , EBP: 
sptr|S(-8)l  B4Arw::B4Arw::B4Ax::B4Ax::B4Ax::B4Ax::({  ESP:  sptr[S(0)]  B4:;B4::sl , EBP: 
sptr[S(nl)]  *1 . EAX:  B4  })Ax::B4::B4::sl } > 
inc  dword  ptr  (-4) [ebp] 

L5: 

LABELTYPE  < Ali|  si:  Ts.nl:  Sint  ].{  ESP:  sptrlS<0)]  B4Arw::B4Arw::B4Ax::B4Ax::B4Ax::B4Ax:: 

({ ESP:  sptrlS{0)l  B4::B4::sl , EBP:  sptr[S(nl)l  si , EAX:  B4  })Ax::B4::B4:*l , EBP: 
sptr(S<-B)|  B4Arw::B4Arw::B4Ax::B4Ax::B4Ax::B4Ax::({  ESP:  sptr|S(0)|  B4::B4::sl , EBP: 
sptr[S(nl)l  si , EAX:  B4  })Ax::B4::B4:;sl } > 
mov  edi, dword  ptr  (24) [ebp] 
cmp  dword  ptr  (-4) [ebp] ,edi 
jl  tapp(  L2,  < si,  nl  > ) 


